数据库代码化——黄金三镖客
在讨论「数据库代码化 (Database-as-Code / DaS)」之前,让我们先讨论一下一个更普遍的概念,即 “配置代码化 (Configuration as Code / CaC)”。CaC 是在代码库中管理配置资源的做法。典型的配置资源包括:
基础配置,如计算 (虚拟机),网络资源 (负载平衡器)。由于 HashiCorp Terraform、AWS CloudFormation 等工具的流行,这一系列资源配置被称为「基础设施代码化 (Infrastructure-as-Code / IaC)」
监控和告警配置
访问权限控制策略 (Identity and Access Management / IAM)
持续集成 (Continuous Integration / CI) / 持续交付 (Continuous Delivery / CD) 配置,如 GitHub Actions, GitLab CI
功能开关 (Feature Flag)
最后也是最重要的,我们今天的主角,数据库 schema,又称「数据库代码化 (Database as Code)」
对于一些类型的配置资源,在代码库中管理它们已经成为事实标准,比如用 HashiCorp Terraform 管理基础设施,通过 Prometheus 管理监控 / 告警配置。
与管理应用程序的代码一样,管理应用数据库 schema 也是软件开发过程中的日常操作。而说到变更数据库 schema 的实践,则有 3 套方案:
直接连接到数据库,并进行 DDL 变更。简单直接,但容易出错。
开发人员通过一个审核控制台,提交一个 DDL 工单,由 DBA 进行审核。DDL 在审核通过后由控制台自动把 DDL 变更到数据库中。这通常被称为 SQL 审核 (SQL Review) 流程。
所谓的「数据库代码化」,在如 GitLab / GitHub 的版本控制系统 (VCS)
中管理数据库 schema,如 GitLab / GitHub。每当开发人员想要进行 schema 变更时,她会创建一个包含这些 DDL 语句的 schema 变更文件并
将该文件提交审查。当审查通过后: 如果自动化程度较高,该变更将触发流水线,自动应用到数据库中;如果自动化程度不高,开发人员仍会使用第一种方法,直接连接到数据库,手动进行变更。
好的 (The Good)
目前业界已经达成共识,认为「配置代码化 」是优于通过 UI 界面进行配置的方法。相应的,将数据库 schema 进行代码化也不例外。在我们看来,schema 代码化有 3 大优点:
充分利用现有的代码库基础设施,避免重复工作。我们可以免费获得诸如代码版本 / 分支管理、代码审查、代码搜索等功能。像 GitLab / GitHub 这样的产品已经在这些方面投入了巨大的资源。
与持续集成 (CI) 和持续交付 (CD) 的 DevOps 工作流程保持一致,通过回放 (replay) 存储在仓库中的 schema 变更文件,自动准备本地/测试数据库的过程。
拥有唯一的可信来源 (single source of truth / SSOT),即存储在仓库中的数据库 schema 文件。有了 SSOT,开发环境可以在不连接到生产数据库的情况下进行诸如 schema 漂移检测 (schema drift detection)、分析数据库 schema 这类的操作。没有开发环境下的 SSOT,这样的操作是很困难的,因为生产网络通常与开发网络相分离。
坏的 (The Bad)
坏的 (The Bad)
丑的 (The Ugly)
丑的 (The Ugly)
困难的初始化配置
首先团队要搞清楚如何组织 schema 文件以便管理不同环境下的数据库 schema 变更。而如果想要设置一提交 schema 变更文件便能触发 schema 变更的自动化工作流,需要:
通过 OAuth 获得 VCS 实例的 root 访问权限,然后在 VCS 项目中设置适当的 webhook,并要正确设置监听的仓库目录。
在此基础上,团队还会自定义规则,比如只允许 dev, test 环境的数据库 schema 变更可以自动进行,而仍然针对生产 (production) 环境的变更进行人工审核。
进程缓慢 - 没有持续正反馈
类似 schema 漂移检测这样的功能只有在代码库和数据库服务器之间具有
更深的集成时才可能实现,前者需要存储代码版本的信息,后者需要存储 schema 的所有变更历史记录。除了数据库和代码库,它还需要更高层次的抽象来对协作开发工作流进行
建模,比如像项目 (project),工单 (ticket) 这样的容器,以提供一个完整
的解决方案。为了构建一个真正自动化的数据库 CI 流水线,它不仅需要回放 schema 变更文件,而且还需要构建测试数据,这通常需要与应用逻辑的集成。
可运维性欠佳的开源数据库
Bytebase 团队在数据库方面已经深耕 10 多年了,曾经在 Google Cloud SQL 和蚂蚁集团 OceanBase 管理过全球数一数二规模的数据库集群。我们做 Bytebase 就是为了扫清团队在采用「数据库代码化」这个最佳实践中的障碍:
我们为团队提供了一个 web 控制台,以便在数据库相关任务上进行协作。
Bytebase 为用户提供细化到每一步的点击向导, 来进行「数据库代码化」和 诸如 GitLab 这样代码仓库相关的初始配置。
如果用户还不想一步走到数据库代码化的方案,Bytebase 也提供完全基于 UI 界面的 SQL 审查解决方案。
BTW,如果你喜欢这篇文章,你可能也会对我们的产品 Bytebase 感兴趣,这是一个开源的、网页版的 schema 变更和版本控制工具。试试我们的实时演示或查看我们的安装指南(只需一个命令行,如果你已经有了docker,5秒钟就可以完成安装)。